Signed-off-by: Kevin Svetlitski <ksvetlitski@janestreet.com>

This is useful for testing.

Signed-off-by: Kevin Svetlitski <ksvetlitski@janestreet.com>

This is in preparation for writing the new backend. After we've made substantial
changes to `src/new_trace_writer.ml`, you'll still be able to track the history
by running:
```bash
git blame -C -C src/new_trace_writer.ml
```

Yes, you need to pass `-C` *twice*:
> -C ... when this option is given twice, the command additionally looks for copies
  from other files in the commit that creates the file.

Signed-off-by: Kevin Svetlitski <ksvetlitski@janestreet.com>

The existing `Trace_writer` module works well enough (albeit not perfectly) most of the
time. However, it is difficult to reason about, in large part because it writes the
trace in a streaming fashion. That introduces significant additional complexity and
book-keeping, and limits the ability of the trace-writer to make use of information
discovered later in the trace (I believe the latter is why traces produced today often
have the few frames closest to the root wrong). Because we want to extend the trace-writer
in the near future, we're starting fresh with a different design that's easier to reason about.
The new implementation currently exists alongside the original, but the goal is to eventually
replace it entirely.

Instead of writing the trace in a streaming fashion, we construct an internal
representation of the trace in memory, and write out the trace in a separate, final pass
once all of the events have been consumed. The module responsible for doing most of the
heavy lifting is the new `Trace_segment`, which represents a continuous, **lossless, and
error-free** segment of the trace; we create a new trace-segment whenever we encounter an
error.

**This PR does not represent a complete, finished product.** The code here does indeed work,
and already produces better traces than the existing backend in several cases, but has several
critical pieces missing:
- [ ] Trace-segment stitching: At present we naively treat each trace-segment as
  disjoint. We need to add an additional "stitching" pass before the trace is written out,
  making a heuristic, best-effort attempt to join together adjacent trace-segments in a
  way that preserves control-flow continuity.
- [ ] OCaml exception handling logic when OCaml-specific debug-info is *not* available
- [ ] Golang support (are we keeping this?)

It should also go without saying that while this code appears to work well on the traces I've
tried it on, I would not at all be surprised if there are still bugs/edge-cases.

Signed-off-by: Kevin Svetlitski <ksvetlitski@janestreet.com>

…tation to use

Signed-off-by: Kevin Svetlitski <ksvetlitski@janestreet.com>

Use LLVM to symbolize including inlined frames, and add these to the trace.
This is definitely still a work-in-progress, and also makes the traces *much* larger.

Signed-off-by: Kevin Svetlitski <ksvetlitski@janestreet.com>

Signed-off-by: Kevin Svetlitski <ksvetlitski@janestreet.com>

…`Uopt.t`

Signed-off-by: Kevin Svetlitski <ksvetlitski@janestreet.com>

Signed-off-by: Kevin Svetlitski <ksvetlitski@janestreet.com>

Signed-off-by: Kevin Svetlitski <ksvetlitski@janestreet.com>

Signed-off-by: Kevin Svetlitski <ksvetlitski@janestreet.com>

Signed-off-by: Kevin Svetlitski <ksvetlitski@janestreet.com>

Signed-off-by: Kevin Svetlitski <ksvetlitski@janestreet.com>